1. Field of the Invention
The present invention is directed to computer systems. More particularly, it is directed to verification of portability of computer system applications.
2. Description of the Related Art
The complexity and expense of developing and deploying enterprise-level computer systems applications has been increasing over time. In addition to supporting a rich set of functional features, a modern enterprise application may also have to be scalable enough to support large numbers of concurrent users, and provide a high level of availability, maintainability and interoperability with other applications. The development cycle for a single major release of an application may take months or even years, and may require hundreds of person-years of development resources. As a result, enterprise application vendors are understandably eager to reduce the total cost of application development.
In the past, application vendors often developed a first version of an enterprise application for a particular execution platform (e.g., a combination of a computer hardware architecture and an operating system designed for the hardware architecture), and then ported the application to other execution platforms as needed. Each ported version of the application typically went through a quality assurance test cycle on the corresponding platform. Quality assurance testing, during which the functionality, performance and other features of the enterprise application are tested, often represents a substantial portion of the total expense of application development. In order to reduce porting and testing costs, and also in response to growing customer demand for applications that can be deployed across a variety of hardware architectures and operating systems, in recent years many application vendors have begun to target their applications to application server environments (such as the Java 2 Enterprise Edition (J2EE™) environment) that are intended to be platform-agnostic. Typically, a standards organization (or a collaborative body such as the participants in the “Java Community Process” in the case of J2EE™) is responsible for defining standards for the application server technology in the form of formal specification documents. The specification documents define the functionality and interfaces that must minimally be supported for compliance with a particular version of the application server technology. As application server is typically designed and advertised as being compliant with a particular version of an application server technology, and potential users and developers may consult the specifications associated with that version to determine the set of features supported by the application server. Applications developed in accordance with a particular version of a specification are expected, in principle, to be deployable without modification at any application server that conforms to that version of the specification, regardless of the specific operating system or hardware architecture of the platform on which the application server is executed. Thus, once an application vendor has developed and tested such a portable application on an application server on one platform, no further source code changes should be required to deploy the application on other platforms, and the application vendor should also be able to reduce or eliminate additional testing required for the other platforms.
Unfortunately, application servers provided by different application server vendors may differ slightly in the set of functions and features provided, even where the different application server vendors claim compatibility with the same set of specifications. For example, the specifications may allow optional features to be implemented, and different application server vendors may implement different sets of optional functions. As a result, an application developed on a particular application server may sometimes use features such as application programming interfaces (APIs) that are vendor-specific, and hence may not be truly portable. Also, portability may require compliance with certain standards for run-time behavior, e.g., standards relating to exception handling. Traditional tools for identifying non-portable features of applications may require access to application source code, changes to application server code, restarts of application servers to initiate or terminate portability analysis, and/or cumbersome modifications to an application server runtime environment, which may be difficult to accomplish for application developers and potential customers. In addition, portability criteria may change over time (e.g., as standards or specifications change), and traditional portability verification tools may themselves require source code modifications to adapt to changes in portability criteria.